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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 
No amendment after final has been filed. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
substantially correct. The changes are as follows: 

Claims 5-8 are rejected under 35 U.S.C. § 101 as directed to non-statutory subject matter; 

Claims 1 and 3-20 are rejected under 35 U.S.C. § 1 12, first paragraph, as failing to 
comply with the enablement requirement; and 

Claims 1, 3, 4, and 17-20 are rejected under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 
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The rejection of claims 6-9, 11, and 14-16 under 35 U.S.C. § 1 12, second paragraph, was 
withdrawn in the Final Rejection. (Final Rejection at 2.) However, these claim numbers were 
erroneously reproduced by the examiner in the heading of the rejection as maintained in the Final 
Rejection. {Id. at 12.) 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

No evidence is relied upon by the examiner in the rejection of the claims under appeal. 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claims 5-8 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. 

Descriptive material can be characterized as either "functional descriptive material" or 
"nonfunctional descriptive material." In this context, "functional descriptive material" consists 
of data structures and computer programs which impart functionality when employed as a 
computer component. (The definition of "data structure" is "a physical or logical relationship 
among data elements, designed to support specific data manipulation functions." The New IEEE 
Standard Dictionary of Electrical and Electronics Terms 308 (5th ed. 1993).) "Nonfunctional 
descriptive material" includes but is not limited to music, literary works and a compilation or 
mere arrangement of data. Both types of "descriptive material" are nonstatutory when claimed 
as descriptive material perse. In re Warmer dam, 33 F.3d 1354, 1361, 31 USPQ2d 1754, 1760 
(claim to a data structure per se held nonstatutory). 
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Data structures not claimed as embodied in computer-readable media are descriptive 
material per se and are not statutory because they are not capable of causing functional change in 
the computer. See, e.g., In re Warmerdam, 33 F.3d 1354, 1361, 31 USPQ2d 1754, 1760 (claim to 
a data structure per se held nonstatutory). Such claimed data structures do not define any 
structural and functional interrelationships between the data structure and other claimed aspects 
of the invention which permit the data structure's functionality to be realized. In contrast, a 
claimed computer-readable medium encoded with a data structure defines structural and 
functional interrelationships between the data structure and the computer software and hardware 
components which permit the data structure's functionality to be realized, and is thus statutory. 

Similarly, computer programs claimed as computer listings per se, i.e., the descriptions or 
expressions of the programs, are not physical "things." They are neither computer components 
nor statutory processes, as they are not "acts" being performed. Such claimed computer 
programs do not define any structural and functional interrelationships between the computer 
program and other claimed elements of a computer which permit the computer program's 
functionality to be realized. In contrast, a claimed computer-readable medium encoded with a 
computer program is a computer element which defines structural and functional 
interrelationships between the computer program and the rest of the computer which permit the 
computer program's functionality to be realized, and is thus statutory. See In re Lowry, 32 F.3d 
1579, 1583-84, 32 USPQ2d 1031, 1035. 

Claims 5-8 recite an "apparatus" comprising a series of means that can be reasonably 
interpreted as software, per se. The claim does not define any structural and functional 
interrelationships between the software elements and a computer that would permit the described 
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functionality to be realized when the software is employed as a computer component. 
Accordingly, claims 5-8 appear to merely set forth functional descriptive material per se, which 
is nonstatutory. 

Claims 1 and 3-20 are rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the enablement requirement. The claim(s) contains subject matter which was 
not described in the specification in such a way as to enable one skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and/or use the invention. 

Applicant's specification does not adequately define what is meant by the terms 
"incorrect", "older", or "newer" in the context of the recited determining steps or how a 
determination may be made as to whether a particular file or class may be determined to be 
"incorrect", "older", or "newer". The only apparent description of such functionality is in 
reference to FIG. 5B step 560 (See Specification at p. 13, lines 18-21 (merely repeating the 
desired functionality without describing how it is achieved). 

Applicant's specification does not adequately define what is meant by a user "doing 
debug" or how a determination may be made as to whether such a user "owns" the first/second 
file/class. The only apparent description of such functionality is in reference to FIG. 5B step 575 
(See Specification at p. 14, lines 2-5 (merely repeating the desired functionality without 
describing how it is achieved). 

Further, while the specification illustrates "exemplary" user interfaces (FIGS. 2 through 
4), no description in the specification recites the necessary steps to acquire and display such 
information (See Specification at p. 10, line 24, through p. 12, line 20 (merely describing desired 
features of pictoral representations of exemplary user interfaces). 
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Undue experimentation would be required by one of ordinary skill in the art in making or 
using the claimed invention because the necessary steps in creating any working implementation 
of the invention are well beyond the scope of the disclosure. One attempting to make or use the 
claimed invention would be left entirely on their own to come up with the algorithm necessary to 
start with an event handler capable of receiving an add class event (step 510) and a class path 
(step 515) and produce appropriate determinations as to whether a current class is "newer" (by 
an unspecified standard) or "owned by a user doing debug" necessary to enable the generation of 
a warning (along with a stored reason for the warning). As noted above, while applicant's 
specification and drawings suggest high-level steps of determining whether a class is "newer" 
and "owned by a user doing debug", each of these steps would require several sub-steps, and the 
lack of guidance in the disclosure as to what these sub-steps are would necessitate undue 
experimentation to achieve a working implementation. 

Claims 1, 3, 4, and 17-20 are rejected under 35 U.S.C. 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 

The term "incorrect" in claims 1-4 is a relative term which renders the claim indefinite. 
The term "incorrect version" is not defined by the claim, the specification does not provide a 
standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be 
reasonably apprised of the scope of the invention. 

Regarding claims 17-20, it is unclear what (if any) concrete acts are required by the 
various "configuring" steps recited in these claims. The specification appears to describe 
"configuring"/ "configuration(s)" only in the context of generic hardware arrangements and 
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processing architectures. {E.g., Specification at p. 7, lines 8-11 ("direct access storage devices . . 
. could alternatively be . . . arrays of disk drives configured to appear as a single large storage 
device to a host"); p. 7, lines 21-26 ("the memory bus . . . may be arranged in . . . star or web 
configurations"); p. 9, lines 10-16 ("components other than or in addition to those shown in Fig. 
1 may be present, and that the number, type, and configuration of such components may vary").) 
The specification does not describe any acts associated with these configurations or connect 
them in any meaningful way with the underlying functionality recited in the claims (i.e., the 
configuring/configuration(s) in the specification appear to be limited to illustrating what a 
general purpose computer might be (see, e.g., Specification p. 8, line 26, through p. 9, line 16 
(computer system 100 may be, among other things, a pager, and automobile, or a mainframe)). 
The specification neither describes nor suggests how any particular configuration may be 
specifically associated with or conducive to: "find[ing] a file in a first directory specified in a 
classpath," or "determine[ing] whether the file is an older version," or "issu[ing] a warning if the 
file is the older version." (Claim 17.) Because the unspecified and/or undefined acts associated 
with "configuring" or even their necessary effect are not clear upon considering the claims as a 
whole in light of the specification, one of ordinary skill in the art would not be apprised the 
scope of the claims and, therefore, the claims would fail to serve the notice function required by 
35 U.S.C. 1 12, second paragraph, by providing clear warning to others as to what would 
constitutes infringement of a resulting patent. See, e.g., Solomon v. Kimberly-Clark Corp., 216 
F.3d 1372, 1379, 55 USPQ2d 1279, 1283 (Fed. Cir. 2000). 
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(10) Response to Argument 

a. The rejection of claims 5-8 under § 101 (Brief 23-24) 

Appellants have previously argued that, "[T]he means plus function language of claims 
5-8 may be interpreted, by way of example and not of limitation , as a random-access 
semiconductor memory that stores instructions capable of executing on a processor, as a random- 
access semiconductor memory that stores statements capable of being interpreted by instructions 
capable of executing on a processor, or as hardware implemented via logic gates, all of which are 
physical components, articles, or objects." (Remarks, September 26, 2007, p. 7 (emphasis 
added).) In appellants' brief, appellants now argue that the means plus function of claims 5-8 
must be interpreted as various types of RAM storing instructions or logic hardware (Brief 24). 
However, the specification does not limit the means to these recited structures, but rather goes on 
to explain that, 

[T]he various embodiments of the invention are capable of being distributed as a program 
product in a variety of forms, and the invention applies equally regardless of the 
particular type of signal-bearing medium used to actually carry out the distribution . The 
programs defining the functions of this embodiment may be delivered to the computer 
system 100 via a variety of signal-bearing media, which include . . . information 
conveyed to the computer system 100 by a communications medium, . . . including 
wireless communication . 

(Specification 9-10 (emphasis added).) Such "structures", consisting of either programs defining 

the functions or signals encoded with programs defining the functions, are non-statutory. See In 

re Nuijten, 500 F.3d 1346, 1353, 84 USPQ2d 1495, 1500 (Fed. Cir. 2007). 
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b. The rejection of claims 1 and 3-20 under § 112, first paragraph (Brief 24-28) 

Evidence of the knowledge of one skilled in the art cannot be substituted for an enabling 
disclosure. See Auto. Techs. Int'l, Inc. v. BMW of N. Am., Inc., 501 F.3d 1274, 1283 (Fed. Cir. 
2007) (quoting Genentech, Inc. v. Novo Nordisk A/S, 108 F.3d 1361, 1366 (Fed. Cir. 1997) ("It is 
the specification, not the knowledge of one skilled in the art, that must supply the novel aspects 
of an invention in order to constitute adequate enablement.")). 

The purpose of the requirement that the specification describe the invention in such terms 
that one skilled in the art can make and use the claimed invention is to ensure that the invention 
is communicated to the interested public in a meaningful way. The information contained in the 
disclosure of an application must be sufficient to inform those skilled in the relevant art how to 
both make and use the claimed invention. MPEP § 2164. 

As the CCPA observed in Sherwood, the writing of a program may require varying 
degrees of skill: 

In general, writing a computer program may be a task requiring the most sublime 
of the inventive faculty or it may require only the droning use of clerical skill. The 
difference between the two extremes lies in the creation of mathematical 
methodology to bridge the gap between the information one starts with ("the 
input") and the information that is desired ("the output"). 

In re Sherwood, 613 F.2d 809, 816-17, 204 USPQ 537, 544 (CCPA 1980), cert, denied, 450 U.S. 

994, 68 L. Ed. 2d 193, 101 S. Ct. 1694 (1981). 

Given a properly defined program specification or a detailed algorithm (i.e., the "bridge" 

between the input and output, see Id.,) a computer programmer can generally produce an 

acceptable computer program to carry out the functions necessary to implement the program 



Application/Control Number: 10/821,146 Page 1 0 

Art Unit: 2192 

specification. However, where the program specification is lacking, the computer will, in 
general, not relieve the burden on the programmer of filling in the missing details. 
As noted in the Final Office action, 

One attempting to make or use the claimed invention would be left entirely on their own 
to come up with the algorithm necessary to start with an event handler capable of 
receiving an add class event (step 510) and a class path (step 515) and produce 
appropriate determinations as to whether a current class is "newer" (by an unspecified 
standard) or "owned by a user doing debug" necessary to enable the generation of a 
warning (along with a stored reason for the warning). As noted above, while applicant's 
specification and drawings suggest high-level steps of determining whether a class is 
"newer" and "owned by a user doing debug", each of these steps would require several 
sub-steps, and the lack of guidance in the disclosure as to what these sub-steps are would 
necessitate undue experimentation to achieve a working implementation. 

(Final Rejection, December 3, 2007, p. 4 (quoting Non-Final Rejection, June 21, 2007, pp. 5-6).) 

The cited portions of the specification (Figs. 5A and 5B (blocks 505, 510, 515, 520, 525, 

530, 555, 560, 565, and 575); p. 3, lines 26-28; p. 4, lines 1-3; p. 11, lines 25-26; p. 12, line 21, 

through p. 14, line 16) describe only example processing for a classpath controller in general 

terms, including a processing of an add class event, an addition of a class to debug, and turning 

on a warning indicator if a current class is "newer" than a previously added class or if a current 

class is "owned" by a user "doing debug". Further, the remaining portions of the specification do 

not describe the conditions under which a class is an incorrect version, but only describe in 

general terms a scenario in which a classpath controller, " suspects that the associated class . . . 

may be the incorrect version." (Specification 14.) Thus, the disclosed system would appear to 

be capable of, at best, a guess as to whether a class may be "incorrect", rather than determining 

or even properly defining any actually "correctness" such that the claimed invention can be 

carried out without undue experimentation. 
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Appellants suggest that, "the ordinary dictionary meaning of the terms 'older' and 
'newer'," is used, (Brief 26) citing Merriam- Webster Collegiate Dictionary, 10 th ed., 2000 
(providing multiple definitions of the term "new"), The cited definition does not describe or 
even shed any light on how "newer" may be determined by a classpath controller . The missing 
description for how to carry out the step of "determining whether the second class is a newer 
version of the first class," (e.g., claims 5 and 9), is still missing after considering the ordinary 
definition of "new" offered by appellants. Appellants further make the unsupported assertion 
that, "determining whether one file is older or newer than another is a trivial exercise for a 
person of ordinary skill in the art." (Id.) The arguments of counsel cannot take the place of 
evidence in the record. In re Schulze, 346 F.2d 600, 602, 145 USPQ 716, 718 (CCPA 1965). 
Further, even if appellant's assertion of the level of knowledge of one skilled in the art were 
supportable by evidence, such evidence cannot be substituted for a basic enabling disclosure. 
See Auto. Techs. Int'l, 501 F.3d at 1283. As noted in the previous Office actions (e.g., Final 
Rejection at 5), the only apparent description of such functionality is in reference to FIG. 5B step 
560 (See Specification at p. 13, lines 18-21 (merely repeating the desired functionality without 
describing how it is achieved)). 

Although appellants' mock-ups of desired user interfaces may be achievable in the 
broadest sense (e.g., displaying static text in a popup window) using known hardware and known 
user interface concepts, however it is the displayed information itself that is at issue. As 
discussed above, appellants' disclosure does not fully support the various determining steps 
regarding the class path controller such that a display of such warnings can be derived from the 
input class path. The mock-ups of an intended GUI are merely prophetic examples rather than 
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representing actual working examples that would help support appellants arguments of 
enablement. 

Appellants assert that, "File and class ownership are well known to persons of ordinary 

skill in the art." (Brief 27). To support this assertion, appellants cite an illegible copy of a 

dictionary entry for the term "class" and a definition for "file owner" described only in terms of a 

user of an AIX operating system and not describing how such ownership may be determined by a 

classpath controller. The assertion and evidence provided still do not address the concerns raised 

in the previous Office actions: 

Applicant's specification does not adequately define . . . how a determination may be 
made as to whether such a user "owns" the first/second file/class. The only apparent 
description of such functionality is in reference to FIG. 5B step 575 (See Specification at 
p. 14, lines 2-5 (merely repeating the desired functionality without describing how it is 
achieved). 

(Final Rejection at 6 (quoting Non-Final Rejection at 5).) 

[W]hile applicant's specification and drawings suggest high-level steps of determining 
whether a class is "newer" and "owned by a user doing debug", each of these steps would 
require several sub-steps, and the lack of guidance in the disclosure as to what these sub- 
steps are would necessitate undue experimentation to achieve a working implementation. 

(Id. (quoting Non-Final Rejection at 6).) 

A common theme of appellants' arguments has been to provide dictionary definitions of 

terms used in the claims and disclosure (appellants have cited definitions of: "configure", "new", 

"class", "file owner", "icon", "keyboard", "terminal", and "window"; (Brief at 26-27)), and to 

assert that this is enough to enable claims that recite only vague notions implicating those words. 

(E.g., Brief 26.) However, the test for enablement is not whether individual words in the claim 

are known, but rather whether the disclosure as a whole provides sufficient information to inform 

those skilled in the relevant art how to both make and use the claimed invention without undue 
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experimentation. Indeed, every single word in appellants' claims may be found in one or more 

dictionaries, but a dictionary is not a universal "how-to" manual capable of reducing or 

eliminating the experimentation required to practice appellants' claimed invention. 

c. The rejection of claims 1, 3, 4, and 17-20 under § 112, second paragraph (Brief 28- 
29) 

Claims 1,3, and 4 

Appellants' claim 1 recites, "wherein the determining whether the first file is the 
incorrect version further comprises determining whether a second file later in the classpath from 
the first file is an earlier version that the first file." (Claim 1 (emphasis added).) Rather than 
providing a clear definition of the term "incorrect", the claim merely provides that the previously 
undefined and indefinite step has one or more additional substeps (i.e., the open-ended phrase 
"further comprises" is used rather than a more limiting and defining language). 

The cited portions of the specification (Figs. 5A and 5B (blocks 505, 510, 515, 520, 525, 
530, 555, 560, 565, and 575); p. 12, line 21, through p. 14, line 16) describe only example 
processing for a classpath controller in general terms, including a processing of an add class 
event, an addition of a class to debug, and turning on a warning indicator if a current class is 
"newer" than a previously added class or if a current class is "owned" by a user "doing debug". 
Further, the remaining portions of the specification do not describe the conditions under which a 
class is an "incorrect" version, but only describe in general terms a scenario in which a classpath 
controller, " suspects that the associated class . . . may be the incorrect version." (Specification 
14.) Thus, as noted above, even if appellants had provided an enabling disclosure (see the 
rejection under § 1 12, first paragraph), the disclosed system would appear to be capable of, at 
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best, a guess as to whether a class may be "incorrect", rather than providing any concrete 
definition of what correctness means in this specific context of classpath processing. 

Claims 6-9, 11, and 14-16 

The rejection of claims 6-9, 11, and 14-16 under 35 U.S.C. § 1 12, second paragraph, was 
withdrawn in the Final Rejection. (Final Rejection at 2.) However, these claim numbers were 
erroneously reproduced by the examiner in the heading of the rejection as maintained. (Id. at 
12.) 

Claims 17-20 

Regarding claims 17-20, it is unclear what (if any) concrete acts arc required by the 
various "configuring" steps recited in these claims. The specification appears to describe 
"configuring"/ "configuration(s)" only in the context of generic hardware arrangements and 
processing architectures. (E.g., Specification at p. 7, lines 8-1 1 ("direct access storage devices . . 
. could alternatively be . . . arrays of disk drives configured to appear as a single large storage 
device to a host"); p. 7, lines 21-26 ("the memory bus . . . may be arranged in . . . star or web 
configurations"); p. 9, lines 10-16 ("components other than or in addition to those shown in Fig. 
1 may be present, and that the number, type, and configuration of such components may vary").) 
The specification does not describe any acts associated with these configurations or connect 
them in any meaningful way with the underlying functionality recited in the claims (i.e., the 
configuring/configuration(s) in the specification appear to be limited to illustrating what a 
general purpose computer might be (see, e.g., Specification p. 8, line 26, through p. 9, line 16 
(computer system 100 may be, among other things, a pager, and automobile, or a mainframe)). 
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The specification does describe or suggest how any particular configuration may be specifically 
associated with or conducive to "find[ing] a file in a first directory specified in a classpath," or 
"determine [ing] whether the file is an older version," or "issu[ing] a warning if the file is the 
older version." (Claim 17.) Because the unspecified acts associated with "configuring" or even 
their necessary effect are not clear upon considering the claims as a whole in light of the 
specification, one of ordinary skill in the art would not be apprised the scope of the claims and, 
therefore, the claims would fail to serve the notice function required by 35 U.S.C. 1 12, second 
paragraph, by providing clear warning to others as to what would constitutes infringement of a 
resulting patent. See, e.g., Solomon v. Kimberly-Clark Corp., 216 F.3d 1372, 1379, 55 USPQ2d 
1279, 1283 (Fed. Cir. 2000). 

Appellants have suggested that "configuring" in claim 17 is being used, "with the 
ordinary dictionary meaning," (Brief 28-29) citing Merriam- Webster Collegiate Dictionary, 10 th 
ed., 2000 ("to set up for operation esp. in a particular way <a fighter plane configured for the 
Malaysian air force>"). This argument, essentially asserting that "configuring" means 
"configuring," fails to address the rejection or suggest any measurable metes and bounds of 
claims 17-20. The issue is not what the ordinary meaning of the word "configuring" is, but 
rather whether the mere use of the word "configuring" with the intended functionality specified 
in claims 17-20 is sufficient to allow one of ordinary skill in the art to arrive at a meaningful 
construction of the claims so as to fully understand and appreciate their scope. The examiner 
maintains that such a meaningful claim construction is not possible. 
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(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 



/Eric B. Kiss/ 
Eric B. Kiss 

Primary Examiner, Art Unit 2192 
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/Tuan Q. Dam/ 
Tuan Q. Dam 

Supervisory Patent Examiner, Art Unit 2192 



/Wei Y Zhen/ 
Wei Y. Zhen 

Supervisory Patent Examiner, Art Unit 2191 



